


SESSION REPORT | ESHAnes 








61 B233 MVS For. Small Systems Users [6O 
SHARE NO. _ SESSION NO. SESSION TITLE ATTENDANCE 
MVS Project | John Cotto CHP 
PROJECT ' SESSION CHAIRMAN INST. CODE 
55 Merritt Blvd. Trumbull, CT 06611 (203) 377-2300 — — 


SESSION CHAIRMAN’S COMPANY, ADDRESS, and PHONE NUMBER 


MVS FOR SMALL SYSTEMS USERS 
Roger C. Lauzon 


Computer Centre 
University of Windsor 
Windsor, Ontario 
Canada NOB 3P4 

(519) 253-4232, X 648 


Installation Code: UOW 


MVS Project 


Session B233 
August 25, 1983 


T8t 


INTRODUCTION 


The University of Windsor is a small university with 
some 8,500 full-time and 4,500 part- -time students. Almost all 
academic and administrative computing is performed in one data 
processing centre run by the Computer Centre department that is 
open seven days a week, RWEREYrtOeD hours a day. 


The Computer Centre is a small to intermediate size MVS 
user. This paper will describe the hardware and software environ- 
ment in the Computer Centre, our experience with MVS, and our con- 
cerns as a small MVS user. 


ENVIRONMENT 


We currently have two IBM 3031's, one with 5 megabytes 
and the other one with 8 megabytes of memory. They each have 
three strings of DASD, all 3350 technology except one string of 
3330-11's which can be sharable but normally is not. Disk stor- 
age is limited; for one CPU we have 4,400 megabytes, whereas the 
other contains 4,800 megabytes. Both CPU's share:six tape drives, 
all unit record equipment (3 printers, 2 readers and 1 punch), and 
a 3705/06 communications controller for some 200 ASCII terminals. 
Each CPU has a dedicated 3274 to support some 50 3270-type termi- 
nals. 
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The 3031-5 operates with MYT under VM/SP. The 3031-8 
runs with MVS/SP 1.3 in native mode. We are in our last stages of 
an MVT to MVS conversion which should be completed By the end of 
the year. At that time, both CPU's will run MVS/SP 1.3, with 
plans for the larger machine to run under VM/SP. 


Come September, the MVS machine will support 15 CICS 
terminals for a Registrar's system, 15 TSO/SPF terminals for staff 
program development, some 60 to 80 concurrent WYLBUR (ASCII) 
terminals for our academic community, as well as a half dozen 
batch initiators. Currently, the WYLBUR terminals and half the 
batch initiators are not being supported under MVS. They are 
presently on the 3031-5 under MVT along with 30 data base termi- 
nals, more WYLBUR terminals, and other batch initiators. 


The 3031-8 was installed this summer. Before that time, 
the 3031-5 ran VM/SP with MVT as the favoured production virtual 
machine, and MVS/SP 1.3 as a 'quasi-production' system. This was 
done only to expedite the conversion to MVS, and it is not a 
recommended practice. 


MVS USER EXPERIENCE 


Currently, the 3031-8 supporting CICS, TSO/SPF and 
batch initiators runs very well. The terminal response time is 
excellent. Paging is at a minimum. But when we tried the same 
functions on the 3031-5, the batch initiators affected the terminal 
response times quite dramatically. But we feel we could have 
improved the situation somewhat if the disks were not so limited 
and would have been set up just for that MVS system, not for VM 
and MVT as well. The difference of 3 megabytes of real memory 
was Significantly apparent to us as well. Come September, when 
we add all the concurrent WYLBUR terminals to MVS on the 3031-8 
system, we feel we will have to back off most of the batch 
initiators during the day shift to achieve good on-line response. 
As well, our on-line usage is not only from 9AM - 5PM, since the 
students use the WYLBUR terminals around the clock. Te achieve 
good on-line response, some other users, normally batch, must be 
cut back. 


When we ran both MVT and MVS under VM on the 3031-5, 
the on-line response on MVS was terrible. Two major factors 
affected this: we favoured MVT as our production machine, and 
we could not run MVS in a V=R environment since we only had 5 
megabytes of real memory. Once we tried running MVS ina 4 
megabyte V=R area, which allowed fairly good response on the 
MVS side, but MVT died. 


CONCERNS AS A SMALL USER 
As a small MVS user, I feel we have some unique concerns 


that are not always shared by the larger MVS users. I would like 
to outline some of them below. 
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In our installation, our budget is not always sufficient 
for our requirements. That could be true in most installations, 
but in smaller shops the percentage of the data processing budget 
required for software would always be higher than a larger installa- 
tion, since basically all the same software is required. Because 
of this, either we do not always acquire the software we should 
have, or we support ‘home-grown' or 'free' software which requires 
more maintenance. As an example, IBM over the last few years has 
added different program products to the full MVS IPO system. [In 
themselves, some of these products are not that expensive and most 
large installations already have them. But in our case, each time 
we have to justify this new product. Currently, we use a segmented 
IPO, not the full IPO, because of this. As well, monies to send 
technical staff on courses and to make a regular commitment to 
conferences we should be attending is a problem. 


Each systems programmer ina small MVS shop usually is 
responsible for the support of many different systems or products. 
There is not a situation where one or two people or even a group 
can specialize in a specific area. In this way, there is very 
little backup for a person, if any. It is very difficult to free 
staff for new projects because they are too busy, and if a pro- 
grammer leaves, the shop usually is in difficulty for a given 
period of time. The software environment can also be just as com- 
plex as in larger MVS shops. These complex smaller shops may have 


more manpower than some other smaller shops, but here each individual 


is heavily relied on to support multiple systems as well. 


Tuning an MVS system for a small user is different than 
for a large user. You have similar tuning concerns, but ina small 
shop you do not normally have all the tuning aids and monitors. 
Also, you do not have the luxury to dedicate volumes for swapping 
and paging. Usually you are restricted by a limited amount of DASD 
to perform the proper reconfigurations that you would like to make. 


These are some of the concerns I have come across as 
a small MVS user. 


CONCLUSION 


In conclusion, we feel that MVS can run quite well on 
a 3031 CPU, but like any other CPU that MVS runs on, MVS' per- 
formance is very dependent on the amount of real memory the com- 
puter has and the amount of DASD available to properly lay out 
paging and swapping data sets, and application volumes. Without 
sufficient memory and with a limited amount of DASD, we found 
that we have to restrict the use of the computer resources, 
especially during the prime shift when you are trying to provide 
an acceptable on-line response for your terminal users. We have 
had to cut back on our batch users to provide this response. This 
implies execution of their jobs during off-shifts and a reduction 
in the number of jobs submitted. 
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